A communication network may include network elements that route packets through the network. Some network elements may include a distributed architecture, wherein packet processing may be distributed among several subsystems of the network element (e.g., line cards, switches, and traffic managers). In some instances, a network element used in a communication network may be a multi-function Ethernet aggregation network element. A multi-function Ethernet aggregation network element may be one which supports many functions, including without limitation link aggregation, virtual LAN (VLAN) detection, and traffic management/shaping.
A multi-function Ethernet aggregation network element may include a distributed architecture including one or more plug-in units (PIUs). A PIU may comprise a modular electronic device that provides any suitable network communication functionality. For example, a PIU may include, among other things, an switch (e.g., an Ethernet switch) for switching traffic through the network element and a traffic manager for shaping and/or policing network flows.
In many instances, communication networks may employ link aggregation. Link aggregation (e.g., IEEE 802.1AX-2008) may generally describe the practice of using multiple network cables or ports in parallel to increase the link speed beyond the limits of any one single cable or port, and to increase redundancy for higher availability. In link aggregation, a group or set of ports may be combined and represented as a single logical port to other components of the network system. Various switching elements of the network system may “see” the aggregated ports (known as a “link aggregation group” or “LAG”) as a single logical communication port in the routing tables or databases of network elements external to the LAG.
In addition, to ensure high reliability and availability in communications networks, protection switching is often used. When implemented, protection switching typically provides a primary or “working” path for a network and a redundant or “protection” path for the network. Accordingly, each path of a protection group may be monitored, and if a failure is detected on the working path, network traffic may be switched to the protection path. An example of protection switching may be Ethernet Linear Protection Switching (ELPS) as defined by the ITU G.8031 standard.
In a multi-function Ethernet aggregation network element, the path of traffic to an egress port of the network element may depend on numerous factors. For example, the path to egress may depend on selected internal system links. For example, related network flows may need to be combined to a traffic manager device in an appropriate manner, including flows from different ingress ports of the same LAG (e.g., a 0:N LAG) from two or more PIUs in a network element. Additionally, bandwidth of individual internal system links may not be adequate to carry all ingress traffic, which may require spreading traffic among multiple internal links. Path to egress may also depend whether egress comprising a single port or a LAG, and whether a VLAN associated with the traffic is part of a protection group (e.g., ITU G.8031 protection group). Having established a path to egress, the path may be switched due to an egress protection switch via link aggregation, a protection group protection switch, and/or other occurrence. Such protection switching must occur quickly in order to satisfy relevant communications standards (e.g., ITU G.8031), which requires switching flows as groups, rather than as individual flows. Such path switching must also be accomplished while efficiently utilizing the resources of a network element, which may also require switching flows of groups, in order to conserve Ethernet device classification and policy resources. All of the above may require that internal links of traffic be specified. However, traditional network element components generally provide for identifying specific egress destinations, and not internal links.
In addition, in a multi-function Ethernet aggregation network element, the identity of a flow of traffic may depend on many factors. For example, flows may require device-unique labels as they travel through various logic engines in a switch. The label may identify the flow with sufficient resolution such that all packets of traffic with the same label undergo identical treatment in a logic engine. Thus, on ingress, flows may need to be identified more specifically in order to allow specific treatment for such flows. On egress, flows can be treated in the aggregate. As an illustrative example, flows may enter a client port of a network element with different customer VLAN tags (also known as C-tags). On ingress, each flow may be classified and processed per its VLAN C-tag, or a label traceable to such tag. Groups of these customer flows may receive an additional subscriber VLAN tag (also known as an S-tag) on egress. On egress, these flows may be classified and identified by their S-tag, or a label traceable to such tag. In both ingress and egress, it may be required that the flows be device unique, and labels such as C-tags and S-tags which require classification on system ingress and egress for uniqueness may not be device unique. Uniqueness must be assured by the flow architecture and VLAN assignments within the device, which traditional network element architectures do not allow. In addition, for protection switching, on egress it may be necessary to assign a different egress identifier to a flow for working path and protection path, which may double the number of labels destined for egress. This may cause scalability problems if the labels as defined on ingress also need to be doubled. Traditional network architectures do not provide an efficient means by which to remedy this scalability issue.
Further, traffic managers may be used in network elements in order to police flows from clients and to shape network flows from a client to a network and from a network to a client. Often, a single traffic manager in a network element may not have the bandwidth sufficient to handle all flows or a PIU including the traffic manager may not have enough ports to be sufficient for communications requirements. In addition, a single traffic manager may not provide redundancy. Accordingly, a distribution of traffic management tasks among two or more traffic managers in a network element may be desirable. However, traditional network element architectures do not readily support such distributed traffic management.